【レポート】備えあれば憂いなし！AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント #AWSSummit

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019「備えあれば憂いなし！AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント」のセッションレポートです。

AWS Summit Tokyo 2019

#AWS

#イベントレポート

吉井亮

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

6月14日 13:00-13:40
　備えあれば憂いなし！AWS上のシステム本番稼働前に必ずチェックしたい4つのポイント

セッション概要

セッションの背景
- 本番環境では特に影響が大きいパターン
  - 認識したときには手遅れだった
  - 例ルートユーザーの認証が流出
  - 例インスタンスが1台ダウンして全体がダウン
- 本番に必要な環境を揃えられなかった
  - 侵入テストの申請を忘れたまま
  - インスタンス多数起動しようとしたら上限に達した
- 情報が少なく迷宮入りした
  - インスタンスを削除したらログも削除された
  - サービスのログ機能を有効にしていなかった
4つのテーマ
- セキュリティの備え
- サービスレベルを維持するの備え
- 本番運用開始時の備え
- トラブルシューティングの備え
セキュリティの備え
- 一度漏洩した情報は後から秘匿できない
  - 予め備えておく
- 事例1 ルートユーザーのパスワード流出
  - 管理コンソールに不正ログイン
    - 本番環境への攻撃
    - 仮想通貨のマイニング
  - 万が一の暫定対処
    - パスワードを変更する
    - 作成されたユーザーやIAMアクセスキーを削除/交換する
    - 不正に作成されたリソースを削除する
  - 日常的なタスクにルートユーザー使わない
  - MFAを有効にする
  - ルートユーザーによるアクセスを記録・検知する
- 事例2 アクセスキーを誤って公開
  - ソースコードにアクセスキーを含めたままリポジトリにアップロード
  - 暫定対処
    - 誤ったコミットを削除
    - アクセスキーの削除/交換する
  - ソースコードにアクセスキーを含めず環境変数を使う
  - 一時的なセキュリティ認証情報を使用
  - GitHubに公開したアクセスキーを検知する仕組みを作ろう
- 事例3 S3上のファイルを誤って公開
  - 不適切なポリシーを設定してしまい世界中からアクセス可能な状態に
  - S3 ブロックパブリックアクセスを使って防止する
サービスレベルを維持する備え
- 備えておかないとサービス停止したとき、クイックに復旧しサービスレベルを維持するのは困難
- 事例1 インスタンスダウンによるサービス停止
  - 想定より多いトラフィックによるダウン
  - アプリケーションのバグによるダウン
  - 基盤の障害によるダウン
  - インスタンスを複数用意
    - ELBを使用して負荷分散
    - 問題発生時に異常なインスタンスを切り離す
    - Auto Scaling
- 事例2 非冗長構成のDBダウンによるサービス停止
  - 冗長構成の採用を推奨
    - 異なるAZにスタンバイインスタンス
  - Auroraを検討する
    - レプリカへフェールオーバー
    - 複数のAZをまたぐボリュームデータのコピー
- 事例3 DDoSの影響によるWebサイトダウン
  - 発生してから対処は難しい
  - AWS WAF レートベースのルール
    - レート制限を超えたアクセスはブロック
  - AWS Shield Advanced
    - DDoSレスポンスチームと連携
本番運用開始時の備え
- 上限緩和、侵入テストの手続きに時間がかかる
  - 必要な手続きは余裕をもって進めていく
- 事例1 上限緩和手続き忘れ
  - 余裕をもって上限緩和の申請
  - オンデマンドキャパシティ予約
  - 長期利用であればゾーンRIを検討
トラブルシューティングの備え
- 重大なトラブルが発生、調査に必要な情報が揃っていないと遡って情報取得は難しい
- 必要な情報は記録しておくことが重要
- 事例1 アクセスログの有効化漏れ
  - ALBで特定時間のエラー原因を調査したいがアクセスログを取得していなかった
  - 本番環境で利用中のサービスはログ有効化
- 事例2 リソース削除時のログ保全忘れ
  - Auto Scalingによってインスタンスが削除されログファイルも削除された
  - Auto Scaling ライフサイクルフックを使う
    - インスタンス削除処理を一時停止しログを回収
  - CloudWatch Agentでログ収集
    - 突然インスタンス停止してもそれまでにログは保全
本番環境に約立つAWSサポート
- Trusted Advisor
  - アカウント内のリソースを分析して推奨事項を提案
  - 分析される項目は5つ
    - 例セキュリティの項目
    - アクセス元が 0.0.0.0/0 のセキュリティグループルールを検出
- AWSサポートプラン
  - ベーシック、開発者、ビジネス、エンタープライズ
  - 本番環境ではビジネス、エンタープライズを推奨